Generating custom reports to assist end users in understanding data is a central requirement in many business environments. Storing the appropriate data in computer systems alone does not allow end users to understand the data in a way that will help them make business decisions. To promote effective data analysis, reports are developed to display the data in a configuration that can be understood by the business users.
The requirements for the reports that are needed by the business units are dictated by the business users. However, in many reporting systems, the actual development or programming of the reports is too complex for the business users, who are generally non-technical users. Thus, the task falls to report developers, who are Information Technology specialists, not specialists in the particular business area of the business user, to generate the reports needed by each business unit.
While the report developers are not familiar with the business, the business users are not familiar with the technology infrastructure. Often, there is information lost in translation when these two groups communicate, which can result in inefficiencies in the business process.
In most organizations, the personnel in the Information Technology department who are qualified to program reports are far outnumbered by the business users. Thus, reporting needs of business users cannot always be met promptly. Information Technology personnel may also attempt to consolidate reporting requests made by non-technical personnel in order to reduce the workload. Although creating a report that can be used by more than one business unit is desirable, sometimes the specifics that each business user may prefer must be sacrificed. So although the reporting request can be filled faster, the end result may not be ideal for any of those people who will use the report.
A reporting system where business users can design and execute their own reports is desirable. This system allows the business users to get what they want without having to articulate their needs to the report developers.
There are some ad hoc reporting systems, such as Crystal Reports and Business Objects, which have presented business users with graphical user interfaces that allow them to generate their own reports. However, these systems have proved complicated for business users, so companies that purchased this software have reverted to relying on report developers to program the reports and then the end users, the business users, generate the reports. In these systems, the report is designed, programmed, and configured by the report developer and the business user, at most, hits a button to “run” the report.
When business users are limited to running reports only, they lose flexibility because they do not have the full range of design capabilities open to the report developers. Once a report is in use, a business user may need to have a small change made to the report because of a changed business need or a mistake in the original requirements. When business users can only run the report, the developer must become involved in every small change so business needs cannot always be met promptly.
Another problem with this distribution of labor is that a business user will have no understanding of what is a difficult and time-consuming change and what is a small change. When the business user gives the requirements to the report developer, the business user may leave out some information that he or she needs. When requesting the addition to this report, what seems like a “small change” to the business user, who is unfamiliar with report development, is actually very time-consuming. Also, had this “change” initially been included in the original specification, the report developer may have taken a different approach. Sometimes it is extremely difficult to make changes midstream.
But allowing business users to develop their own reports can waste company resources. In a complicated reporting system, a business user who is not a professional report developer will take a large amount of time to develop reports, time that could be better spent in that person's business role. Sometimes business users are so unsuccessful that a professional report developer must be called in after the business user wastes time attempting to design a report.
Even a business user who is successful in developing a report could make mistakes. Unfamiliar with the data architecture, the business user could create a flawed report, which could influence business decisions. Even if the report is accurate, the business user may not have crafted it in a way that used Information Technology resources efficiently. A business user may develop a report that, when executed, wastes database and network resources and causes problems for the Information Technology department and other users on the network.
A reporting system and method is needed that guards the efficiency of the technology infrastructure from the non-technical business user, but still allows this non-technical business user to access reports with enough flexibility that every change request does not necessitate the involvement of a professional report developer.